1. Field of the Invention
The invention relates to interfaces for interchangeable peripheral devices in computer apparatus, and more particularly, to an interface which allows both authenticity checking and configuration download while minimizing the physical and electrical differences with prior art interfaces.
2. Description of Related Art
It has become commonplace for hardware developers of interactive home entertainment systems to also develop and sell software for use with such systems, and/or to license other software vendors to do so in exchange for a royalty. In many situations the market for the software is highly lucrative, and indeed may be more important to the original hardware developer than sales of the base system. For the company that has invested heavily in the development of the initial product, the success of the venture may well depend upon the ability to successfully develop and market (or license others to develop and market) software useable with the base system. All too often, however, other vendors develop additional software for the product or even copy the proprietary software from the original manufacturer or a royalty-paying licensee, and capture the market for supplemental software, unburdened as they are with heavy development expenses in the hardware and initial software.
The problem of unlicensed software vendors is not limited to the simple usurpation of revenues which rightfully belong to the original developer of the system or a valid licensee, although that problem can be substantial by itself. There is also the additional problem that unlicensed software vendors do not work closely with the developer of the system and cannot be supervised as to the quality and true compatibility of their software. To the extent that unlicensed software vendors sell software which does not meet the quality and compatibility standards of the original developer, the product's reputation among the consumer public can suffer and the venture's success could be further undermined by reduced sales due solely to an unjustly damaged reputation.
A number of techniques have been developed to try to protect against the problems caused by unlicensed software vendors. For example, one technique requires that a predetermined secret code be included at a predetermined location in the software. Only the original system developer (and valid licensees, in some cases) know the code and/or the location at which it must appear. The host system checks for the code in the predetermined location before it will execute any software. In another technique, the code is checked periodically during the execution of the software in order to ensure that previously authenticated software is not removed and replaced by fraudulent software during execution. In yet another technique, the software contains a digest which is encrypted according to a data encryption key known only to the original system developer. (See U.S. Pat. Nos. 4,405,829, 4,200,770, 4,218,582 and 4,995,082, all incorporated by reference herein.) The system checks the encrypted digest either once or repeatedly during execution of the software.
As a separate matter, a large number of plug-in devices have been developed for the personal computer market. Such devices allow a user to enhance the functionality of a computer by adding additional equipment which is specific to the user's personal needs. Certain home entertainment systems also provide a plug-in port which users can use to enhance their systems in a similar manner. Such a capability allows each user to customize the product for his or her own purposes, without burdening the remainder of consumers with the expense of equipment they might not need for their own purposes. Such additional equipment useful for interactive home entertainment purposes might include non-volatile memory cards to store the current state of a game, for example, or various peripheral devices such as a modem or audio input/output devices. It might also include devices which contain ROM-stored data, such as game "personality modules."
If the additional equipment is sold separately from the base system, and is manufactured either by the same manufacturer as the base system or by other licensed and royalty-paying manufacturers, such equipment carries the same risks of unauthorized manufacture and sale as does software. The problem with respect to plug-in cards is exacerbated, however, because such devices do not necessarily contain software to be executed by the base system; the above-described authentication techniques involving secret codes or encrypted digests would not be appropriate for such devices. Thus a different authentication mechanism is needed if plug-in cards are to be protected from piracy.
Moreover, it is desirable to permit such plug-in cards to contain software to be executed by the base system. In this way a (licensed) software vendor can sell software to consumers either in the form of a CD-ROM (if the base system includes a CD-ROM player) or in the form of a plug-in card. A vendor would also be able to provide proprietary functions on a plug-in card, and include, on the same card, the low-level software drivers to be executed by the base system in order to operate such functions. While unlicensed manufacture and sale of plug-in cards can damage the developer of the original system in the same ways as described above, the potential that such cards can contain software to be executed by the base system would increase the danger of fraudulent activity greatly. A need therefore exists for an authentication mechanism for plug-in cards which will work whether or not the card contains software to be executed by the base system.
For software which is downloaded from a plug-in card prior to being executed by the base system, the above-described techniques involving secret codes or encrypted digests could provide adequate protection against fraudulent software distributed on plug-in cards. One of the advantages that card-distributed software has over CD-distributed software, however, is that the base system can be designed to allow card-distributed software to "execute-in-place" (XIP). That is, instead of downloading the software into the memory of the host system and then executing it from the host system's memory, it is desirable to permit the host system to retrieve an instruction from the card, execute it, retrieve the next instruction from the card, execute it, and so on. XIP capability allows the software to be executed without taking up space in the host system's memory.
But, allowing XIP creates yet another risk of fraudulent activity. For downloaded software, an authenticity check (such as encrypted digest authenticity check) can be performed once on the in-memory copy of the software after download, and need not be repeated on that software because it is thereafter known to be authentic and cannot be replaced by fraudulent software without detection. For XIP software, on the other hand, a single pre-execution authenticity check can be ineffective because schemes can often be devised for substituting fraudulent software after the initial check takes place. Repeated authenticity checks would therefore be advisable for XIP software. But since encrypted digest authenticity checking is a relatively time-consuming process, such repeated authenticity checks would introduce significant execution delays which may be noticeable to a user. At least the encrypted digest authentication mechanism would therefore be commercially impractical for protecting against fraudulent XIP software.
In the past, several video game systems were available for which software was sold in the form of plug-in cartridges. Authentication techniques were developed for such cartridges, and these techniques do not depend on the fact that the cartridge contained software to be executed by the base system. In one such technique, the connector through which the cartridge communicates electronically with the base system carries essentially a complete I/O bus, including address, data and control signal lines. The base system executes the software in the cartridge by performing read data access cycles on this bus, to retrieve the individual software instructions to be executed. Additionally, one contact on the connector is dedicated for carrying a serial bit stream from the cartridge into the base system, and another contact is dedicated for carrying another serial bit stream from the base system into the cartridge. Yet a third contact is dedicated to synchronizing the two bit streams. These three dedicated security-related signal lines are additional to the signal lines of the I/O bus. The base system and the cartridge also both contain identical "security devices", which generate the serial bit streams transmitted across the connector. The two serial bit streams are generated by sequential circuitry which is clocked by the same clock signal that is included in the control signal lines of the I/O bus. In the base system, the bit stream arriving from the cartridge is compared with the bit stream being generated locally, and as long as the two bit streams match, the base system is allowed to continue executing the software. If they fail to match, then execution is aborted. C.f. U.S. Pat. Nos. 4,799,635 and 5,004,232, both incorporated by reference herein in their entirety.
While the above technique can as a technical matter be used in systems where the cartridge is a functional unit such as a modem, and does not contain software to be executed by the base system, commercially the technique can be difficult to employ. The difficulty arises because many of the non-software-containing peripheral card functions which would be desirable for use with an interactive home entertainment system are usually designed primarily for one of the plug-in card interfaces which are standard in the personal computer industry. For example, many modems, non-volatile storage cards and other devices are designed for the standard connectors and signal specifications set forth in Personal Computer Memory Card International Association (PCMCIA), "PCMCIA Card Standard", Rel. 2.1 (July 1993) (hereinafter "PCMCIA Rel. 2.1 specification", incorporated by reference in its entirety herein). It would be expensive for a manufacturer to re-design such a device as a cartridge for use in an interactive home entertainment system which uses the authentication mechanism described above. The expense arises in part because the connector used in such a system must be of proprietary design in order to include the three dedicated security-related signal lines.
In summary, there is a need for an authentication mechanism which will protect a manufacturer from fraudulent sales of plug-in cards. The mechanism needs to be effective both for cards carrying functional peripheral units and for cards carrying only software to be executed by the host system, and needs to be effective even if such software is to be executed in place and not first downloaded to the host system's memory. Furthermore, the mechanism should minimize any physical and electrical deviations required from some standard interface for which peripheral units may already be designed. Encrypted digest techniques exist which would provide effective authentication for cards carrying software, but they provide no authentication for cards which do not carry software. They are also commercially undesirable for cards carrying XIP software. Security bit stream techniques also exist which can provide effective authentication for cards with or without software, but these techniques require proprietary interfaces which deviate significantly from standards for which peripheral units may otherwise be designed. No mechanism is currently available which can be used with peripheral cards whether or not they contain software to be executed by the base system, and which allows authenticity checking while minimizing the physical and electrical differences with prior art standard interfaces.